In the field of database management systems, a database is often referred to as a server; that is, a program that provides services (e.g., via a plurality of processes) to one or more clients. The database generally contains a number of tables, each table having numerous rows and columns. A column is commonly referred to as a “field”, and a given row and field pair is referred to herein as a “data cell”. The data cell describes a particular attribute of the subject of a row.
One type of client is called an application program. An application program is a complete, self-contained program that performs a function directly for a user. As used with a database, the application program provides an interface to the data cells stored in the tables of the database.
An application program is advantageous to a user because the application program provides a simplified interface to the data stored in the database. The interface is simplified because users are generally not required to know complex structured query language (“SQL”) commands that are used to extract data from the database. For example, the application program can provide a graphical user interface (e.g., a “form”) with a series of prompts for query parameters. A user accessing the application program simply enters the query parameters and the application program invokes a SQL request that is processed by the database. The database will return the results of a query matching the user's query parameters to the application program.
As mentioned above, the database is often used as a repository of data information for a number of application programs. Each application program is often designed for a particular type of function and a particular class of user. For example, the database may include a table, the table containing information about employees of a corporation, such as: name, employee ID, social security number, salary, manager, work phone number, and home address.
All of the employees (users) in a corporation do not need full “write” privileges (i.e., the right to update, delete or modify) to the employee data. For this reason, a database may employ a security system to restrict user privileges to the data. For instance, an employee's manager may be granted privileges to read and modify the employee's salary, yet other employees of equal or “lower” rank may be restricted from such privileges by the security system.
FIG. 1 depicts a flow diagram of a secret-based database security system 100. The secret-based database security system 100 is employed to enable privileges to users for access to the data cells. A secret password is authenticated before database privileges are enabled to the users. In short, the secret password is the database's way of determining the identity of an end application (or user).
Often a separate application program is provided for creating, deleting or modifying data cells versus simply reading the cells in the same database. For instance, the employee's manager may update the employee's salary through a payroll application program that allows such database privileges to be granted only to a higher-ranking employee. Furthermore, the payroll application may only reveal certain fields to the employee's manager (e.g., the employee's home address may be withheld, but the employee's salary shown). However, in an electronic mail application, read-only privileges to the employee information table may be granted to all users for corporate directory purposes, but those privileges might restrict access to social security number, salary, and home address information.
In a typical secret-based database security system 100, when the user attempts to access the database through the application program, the application program may first request a password from the user. If the application program successfully authenticates the password, then the application program will establish a session with the database for the user. (As used herein, a “session” is a specific connection of a user to a database instance via a user process; a session lasts from the time the user connects to the database instance until the time the user disconnects from the database instance.) The application program, after establishing the session with the database, will cause an authentication process to be invoked, whereby a password that is hard-coded (or “embedded”) into the application program, or requested directly from the user, will be supplied to the database security system 100 and presumably verified. If the password is successfully authenticated, then the appropriate database privileges are granted to the user.
If the user is denied privileges by using the application program, the user may attempt to establish an ad hoc query session with the database, thereby bypassing the application program. When establishing the ad hoc query session, the same security process is invoked. The authentication process prompts the user for a password and after the user responds, the database security system 100 authenticates the password by comparing the user response with a static password file. If the authentication is successful, then the user is granted privileges to the database.
Drawbacks exist with password, or so-called “secret-based” database security systems. One drawback is that the security is only as good as the password, and the password is only good so long as it is kept secret. Maintaining the password as a secret can be very difficult. For example, one user having privileges to the database can simply supply the password to another user who does not have equal privileges. Another possible breach can occur when an eavesdropper monitors a session and discovers the password, simply checks the application program code for the embedded password, or explores the static password table.
A possible solution is the use of powerful, computationally expensive, multi-bit encryption methodologies in conjunction with the password, such as the well-known Rivest-Shamir-Adleman (“RSA”) or Message Digest 5 (“MD5”) encryption algorithms. However, virtually all passwords and cryptographic methods can be broken. In today's highly distributed client-server systems allowing sessions to be established between tens of thousands of users and the server, it is possible to launch a parallel attack on the database to discover the password. Repeated assaults can be asserted from numerous locations until, eventually, the cryptographic key is discovered and the password is revealed.
Once the password is discovered, it will have to be changed. Users of the database will have to be notified of a new password(s), applications with the password hard-coded or embedded into them will have to modified, and new password tables will have to be created—all at significant effort to the database and/or application program administrator. The userid and password approach to database privilege enablement is not very flexible.